Given the context of why IP law often does more harm than good (especially for indie game developers), this guide strongly suggests using a permissive open licensing approach for your project. This approach maximizes collaboration, community goodwill, and long-term sustainability while still protecting your team's interests.
For a balanced, fair, and collaborative approach, we recommend the following licensing structure:
MIT License Game Code / Entire Game Project
CC0 (Public Domain) Boilerplate Assets
Examples: Things you don't mind giving away for free and without credit, due to how abstract and awkward they are outside the game's context. Or due to how cheap/automatic they are to make that it makes no sense to sell them.
CC-BY 4.0 Instantly Valuable Creative Assets
Examples: Things you want to clearly attach your name to, due to them showcasing your skill as an artist in an easy transferrable way. Or to resell them because they are excellent value, be it as an asset pack, OST, collection or any other side hustle.
Game itself as a whole will be MIT licensed, while assets and writing are either CC0 (context-dependent boilerplate assets) or CC-BY 4.0 (instantly valuable assets with standalone worth).
The key distinction isn't about "unique vs generic" — it's about commercial value and transferability:
What this means for your team:
In other words: The team gets credit for the project, individual artists get credit (and commercial control) for valuable standalone work, but no one person owns the IP nor restricts what its assets can be used for within the project ecosystem.
Not sure which license to use for your contribution? Follow this practical decision tree:
YES → Use CC-BY 4.0
NO → Continue to Step 2
YES → Use CC-BY 4.0 (protect your work and reputation)
NO → Continue to Step 3
YES → Use CC0
NO or UNSURE → Default to CC-BY 4.0
The core principle:
The MIT License is one of the most permissive and widely-used open-source licenses. It allows anyone to:
The only requirements are:
MIT License
Copyright (c) [Year] [Your Team Name]
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.CC0 is the "no copyright reserved" option. It's perfect for assets that are either context-dependent, trivial to create, or have minimal standalone value outside your specific game.
Use CC0 for:
Why CC0 works here: These assets have minimal standalone value. Requiring attribution would be more hassle than benefit. You're not losing anything by releasing them freely — they're awkward to reuse elsewhere anyway.
CC-BY 4.0 allows anyone to use, modify, and distribute the work — even commercially — as long as they give appropriate credit to the original creator.
Use CC-BY 4.0 for:
Why CC-BY 4.0 matters: This allows artists to build their portfolios and reputation. When someone uses their work elsewhere, the artist's name travels with it, creating opportunities for commissions, job offers, and collaborations. Plus, artists retain the right to resell these assets independently for additional income.
your-game-project/
├── LICENSE.md
├── CREDITS.md
├── README.md
├── src/
├── assets/
└── ...# License
## Game Code and Software
This game and its source code are licensed under the **MIT License**.
Copyright (c) [Year] [Team Name]
[Full MIT License text here]
---
## Assets and Creative Content
### Boilerplate Assets (CC0)
Context-dependent or trivial assets are released into the **public domain**
under the CC0 license. These are assets with minimal standalone value or
those so simple that attribution would be more hassle than benefit.
### Instantly Valuable Creative Assets (CC-BY 4.0)
Assets with standalone commercial value, portfolio worth, or significant
creative skill are licensed under **Creative Commons Attribution 4.0
International (CC-BY 4.0)**.
**This means:**
- You can use, modify, and distribute these assets
- You can use them commercially
- You must give appropriate credit to the original creator
- You cannot restrict others from using the original assets
For a full list of contributors and asset credits, see CREDITS.md
---
## Summary for Spin-offs and Forks
You are free to:
- Create derivative works and spin-offs
- Release them commercially or for free
- Modify any part of the game or assets
You must:
- Give credit to the original team and individual creators
- Use a different title/branding to avoid confusion
- Include this license information
- Not misrepresent yourself as the original developersGoal: Get credits done quickly without drowning in tedious documentation. Your team wants to build great stuff, not write boring legal lists.
The Revenue Share System web app has a built-in "Export Credits" button in the Team & Credits tab. Click it to instantly generate a TEAM-CREDITS.txt file containing:
This file is already formatted and ready to use. Rename it to !CREDITS.md when you're done with Step 3.
Tell each team member who created CC-BY 4.0 assets (the valuable stuff worth crediting):
"If you made something you want your name on (for portfolio/resale purposes), send me a text file listing those assets. Only list what matters to you — skip the boring stuff. Format: filename - brief description (optional)."
Example of what an artist sends you:
## Jane Doe - Character Artist
Character_Hero.png - Main protagonist design
Character_Villain.png - Antagonist design
Character_NPC_Merchant.png - Memorable merchant character
Cutscene_Illustration_01.png - Opening cinematic art
Cutscene_Illustration_05.png - Final battle artwork
(CC-BY 4.0 - All my work can be used with credit)Artists only list what they care about. If they made 500 generic tree variants, they don't need to list all 500 — those can fall into the CC0 catchall at the end.
Once you've collected text files from contributors:
ASSET-CREDITS.txtManually combine your two files into the final !CREDITS.md:
# Credits
[Paste TEAM-CREDITS.txt content here]
---
# Asset Credits (CC-BY 4.0)
[Paste ASSET-CREDITS.txt content here]
---
# Licensing Note
All assets not explicitly listed above with individual credit are released
under **CC0 (Public Domain)**. This includes context-dependent assets,
procedurally generated content, and other work with minimal standalone value.
All CC-BY 4.0 contributors retain the right to reuse, resell, or relicense
their individual contributions in their own projects.Why this works: Only valuable assets get detailed attribution. Everything else falls into the CC0 bucket automatically. No one wastes time documenting every single button or sound effect variant.
Your !CREDITS.md file is for legal/documentation purposes. But what about the credits that actually appear in your game?
For in-game credits screens, keep it short and friendly. Players don't need to read legal jargon — they just want to know who made the cool thing they're playing.
════════════════════════════════════
[YOUR GAME TITLE]
════════════════════════════════════
Made by [Team Name]
[Export the team list from the web app here]
• Project Lead - [Name]
• Programming - [Name], [Name]
• Art - [Name], [Name], [Name]
• Music & Sound - [Name]
• Writing - [Name]
• Special Thanks - [Names]
════════════════════════════════════
This game is open-source under the MIT License.
Individual assets may have different licenses.
Full credits and licensing: [link to your !CREDITS.md file]
════════════════════════════════════For loading screens, main menus, or end credits, use one of these short versions:
Made by [Team Name] • Open MIT License
Full credits at [website/github link]Built with love by [Team Name]
Open-source • See full credits at [link][Team Name] • [Year] • MIT LicenseCreated by [Team Name] and contributors
It's open — build on it, share it, credit us ♥Pro tip: Put a clickable link in your game's main menu: Credits & Licenses that opens the full !CREDITS.md file in a browser or text viewer.
Your in-game credits should celebrate your team and be easy to read. Save the detailed licensing stuff for !CREDITS.md. Link to it, but don't force players to read it unless they're curious.
This approach isn't about giving up value — it's about creating more value by being open. You still get credit, you still get paid for official releases, and artists can commercialize their individually valuable contributions. You build a reputation that opens doors far beyond what a locked-down IP ever could.
Note: While MIT is the generally recommended default, depending on your specific project and team composition, you may choose to adopt another license that makes more sense for your situation. The important principles remain the same: openness, proper credit, and community collaboration.
If you have team members in different countries or specific legal concerns, consider consulting with someone familiar with international copyright law to ensure your licensing structure works across jurisdictions.
← Back to App